Consistency checking mechanism for configuration parameters in embedded systems

ABSTRACT

An arrangement is provided for consistent parameter configuration in an embedded system. A consistent parameter configuration mechanism comprises a management client and a configuration manager. When the management client receives a set of configuration requests, it notifies the configuration manager to start a transaction, during which the configuration manager requests relevant embedded modules to perform parameter configurations according to the configuration requests, to manage hard coded dependencies, and to enforce registered dependencies. Any detected inconsistency during parameter configuration causes the consistent parameter configuration mechanism to undo the parameter configuration.

CROSS REFERENCE TO RELATED APPLICATIONS:

This application is a Divisional Application to U.S. patent applicationSer. No. 11/001,938 (Attorney Docket No. 42P11279C), entitled“Consistency Checking Mechanism For Configuration Parameters In EmbeddedSystems),” filed on Dec. 1, 2004 by Iwanojko et al., which is aContinuation Application to U.S. patent application Ser. No. 09/878,431,(Attorney Docket No. P279176/P11279, now issued as U.S. Pat. No.6,877,051), entitled, “Consistency Checking Mechanism For ConfigurationParameters In Embedded Systems),” filed on Jun. 12, 2001 by Iwanojko etal., both assigned to a common assignee, the entire subject matter whichis herein incorporated by reference.

RESERVATION OF COPYRIGHT

This patent document contains information subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction by anyone of the patent document or the patent, as itappears in the U.S. Patent and Trademark Office files or records butotherwise reserves all copyright rights whatsoever.

BACKGROUND

Aspects of the present invention relate to embedded systems. Otheraspects of the present invention relate to configuration of embeddedsystems.

More and more hardware and software products are nowadays developed asembedded systems. They are turnkey products that are often deployed onan “as-is” basis. For example, in networking application domain, variousrouters are embedded systems. To enable an embedded system to functionin different application environments, an embedded system is often builtin a modular fashion, as in a flexible and lightweight operating systemand services (FLOSS) environment.

An embedded system may comprise a plurality of loosely-coupled moduleseach of which may be configurable and may perform a specific function.Each individual module in such an embedded system may be configuredthrough a number of configuration parameters. Different modules may alsobe configured to work together through configuration parameters. In aFLOSS environment, modules depend on each other to some extent. Thedependency may be defined with respect to configurable parameters.However, such dependency relationships are preferably defined loosely sothat a missing or a malfunctioning piece may cause merely insignificantsystem performance degradation instead of overall system malfunction.

Configurable parameters in an embedded system may be accessed andconfigured through setting their values from a management station.Configurable parameters may have their counterparts corresponding torun-time variables used in individual modules. The values of run-timevariables associated with the parameters are set according to the valuesof the corresponding configurable parameters. The run-time behavior ofan individual module can be controlled by setting the values of theirassociated configurable parameters. The collection of such parametersacross an embedded system forms a current configuration database thatdetermines the overall behavior of the entire system. Whenever thecurrent configuration database is changed, the corresponding systembehavior changes accordingly.

Configurable parameters may relate to each other. Two parameters mayrelate to each other through a dependency relationship. For instance,the value of one parameter may depend on the value of another parameter(e.g., if parameter A=2, then parameter B=5). When an embedded system isconfigured, the relationships among different configurable parametershave to remain valid or consistent. That is, the values of configurableparameters need to be set in such a way that the underlying dependencyrelationships remain consistent. Using the above example, when the valueof parameter A is set to 2, the value of parameter B should accordinglybe set to 5 in order for the configuration to be consistent.

Traditionally, configuration consistency of an embedded system isenforced through individual modules. For example, if parameter B inmodule X depends on parameter A in the same module (e.g., A=2, thenB=5), module X has the responsibility to change the value of B to 5whenever the value of parameter A is set to 2. In addition, if parameterC in module Y further depends on parameter B in module X, module X needsto also make sure that module Y has to change the value of Caccordingly. Such an operating method imposes many burdens on individualmodules, making them less flexible, tightly coupled, less modular, andhard to implement.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is further described in terms of exemplaryembodiments which will be described in detail with reference to thedrawings. These embodiments are non-limiting exemplary embodiments, inwhich like reference numerals represent similar parts throughout theseveral views of the drawings, and wherein:

FIG. 1 depicts a high level architecture of embodiments of the presentinvention and the environment in which it operates;

FIG. 2 is a high level functional block diagram of an embodiment of thepresent invention, in which a consistency assurance mechanism interactswith embedded modules and a configuration database;

FIG. 3 shows two exemplary ways of defining a dependency relationship;

FIG. 4 is an exemplary flowchart of a registration process, in which adependency relationship between two embedded modules is registered;

FIG. 5 is an exemplary flowchart of a process, in which consistentparameter configuration is performed;

FIG. 6 is an exemplary flowchart of a process, in which consistencycheck is performed; and

FIG. 7 is an exemplary flowchart of a process to properly end atransaction according to consistency check outcome.

DETAILED DESCRIPTION

The invention is described below, with reference to detailedillustrative embodiments. It will be apparent that the invention to beembodied in a wide variety of forms, some of which may be quitedifferent from those of the disclosed embodiments. Consequently, thespecific structural and functional detail is disclosed herein are merelyrepresentative and do not limit the scope of the invention.

The processing described below may be performed by a general-purposecomputer alone or in connection with a special purpose computer. Suchprocessing may be performed by a single platform or by a distributedprocessing platform. In addition, such processing and functionality canbe implemented in the form of special purpose hardware or in the form ofsoftware being run by a general-purpose computer. Any data handled insuch processing or created as a result of such processing can be storedin any memory as is conventional in the art. By way of example, suchdata may be stored in a temporary memory, such as in the RAM of a givencomputer system or subsystem. In addition, or in the alternative, suchdata may be stored in longer-term storage devices, for example, magneticdisks, rewritable optical disks, and so on. For purposes of thedisclosure herein, a computer-readable media may comprise any form ofdata storage mechanism, including such existing memory technologies aswell as hardware or circuit representations of such structures and ofsuch data.

The present invention addresses automatically establishing consistentconfiguration parameters in embedded systems. FIG. 1 shows a high-levelsystem architecture 100 of embodiments of the present invention, inwhich a consistent parameter configuration mechanism ensures theconsistency of the configuration parameters across all the embeddedmodules in an embedded system. In the system architecture 100 shown inFIG. 1, an embedded system 110 has a set of embedded modules 140 and aconsistent parameter configuration mechanism 120 that receives a set ofconfiguration requests 160 and that ensures a consistent parameterconfiguration to be performed on the embedded system 110 according tothe set of configuration requests 160. Parameter configuration iscontrolled by a consistency assurance mechanism 130 and is executed viathe embedded modules 140. The resultant consistent parameterconfiguration is stored in a configuration database 150.

The configuration requests 160 may be sent to the embedded system 110 torequest a configuration on the embedded system 110 in a desired way. Theconfiguration may involve setting the values of certain configurableparameters used by the embedded modules. The configuration requests 160may be sent using some protocol via a network. For example, the SimpleNetwork Management Protocol (SNMP) may be employed to send theconfiguration requests 160 (SNMP is defined in Request For Comments1157, Network Working Group, Category: Standard STD0015, March 1991.).Using the SNMP, a client (not shown in FIG. 1) may configure and monitorthe embedded system 110 across network.

The embedded modules 140 may represent a set of loosely-coupled modules.Each embedded module may be associated with zero or more configurationparameters. For example, module X may be associated with a configurationparameter A and module Y may be associated with configuration parametersB and C. All the configuration parameters across the entire embeddedsystem 110 form a configuration of the embedded system. That is, aparticular set of values of the configuration parameters corresponds toa specific configuration. When the values of the configurationparameters change, the configuration of the embedded system 110 changes.The value of a configuration parameter may be updated from a managementstation or through the configuration requests 160.

A configuration parameter may have its counterpart in a correspondingembedded module as a run-time variable. Through such run-time variables,configuration parameters determine the behavior of individual embeddedmodules. The overall configuration of the embedded system 110 specifiesthe overall run-time behavior of the embedded system 110. In theillustrated embodiments shown in FIG. 1, an overall configuration forthe embedded system 110 is stored in the configuration database 150.Whenever the configuration is updated, the updated configuration (orcurrent configuration) replaces the originally saved configuration in150.

At anytime, the configuration of the embedded system 110 remainsconsistent. In the present invention, the consistency of theconfiguration is ensured by the consistent parameter configurationmechanism 120. The consistency may be defined prior to parameterconfiguration and may be specified as having valid values with respectto various dependency relationships. Such dependency relationships mayinclude the dependencies among parameters within a single module and thedependencies among parameters in different embedded modules.

In the exemplary embodiments shown in FIG. 1, the consistency assurancemechanism 130 receives the configuration requests 160, executes therequested configurations via the embedded modules 140, and ensures thatthe configurations performed yield consistent parameter setting acrossall involved embedded modules before storing the current parameterconfiguration into the configuration database 150. The configurationdatabase 150 is updated only when the consistency assurance mechanism130 determines that the configuration is consistent.

FIG. 2 illustrates an embodiment of the present invention, whichdescribes how the consistency assurance mechanism 130 interacts with theembedded modules 140 and the configuration database. In FIG. 2, theconsistency assurance mechanism 130 comprises a management client 210, aconfiguration manager 215, a module registration mechanism 262 connectedto a module database 265, and a dependency registration mechanism 260connected to a dependency database 270.

The management client 210 receives the configuration requests 160 fromoutside of the embedded system 110. For example, it may receive SNMPpackets from an outside SNMP management station. The receivedconfiguration requests 160 correspond to a transaction that executes aset of configuration parameter changes. The management client 210 mayalso receive commands from a console terminal requesting changes to bemade to the configuration stored in the configuration database.

The management client 210 controls parameter configuration via theconfiguration manager 215 by requesting appropriate embedded modules toexecute the configuration. To enable the configuration manager 215 toaccess the embedded modules 140, the embedded modules may be registeredthrough the module registration mechanism 262 and the registrationinformation may be stored in the module database 265.

In FIG. 2, the configuration manager 215 comprises a relay mechanism220, a temporary configuration database 230, and a validation mechanism240 with a parameter change signaling mechanism (PCS) 250. The temporaryconfiguration database 230 is created whenever the management client 210informs the configuration manager 215 that a new transaction starts. Thetemporary configuration database 230 is first created as a copy of theconfiguration database 150 and then to be used to host the changes madeto the configuration parameters by the appropriate modules based on thereceived configuration requests 160. This yields a new configuration forthe embedded system 110, which is temporarily stored in the temporaryconfiguration database 230. Such a new configuration may not betransferred (or copied) back to the configuration database 150 untilthey are validated by the validation mechanism 240 as consistent.

The relay mechanism 220 controls different acts performed by theconfiguration manager 215. For example, it may trigger an appropriateembedded module to perform a parameter configuration based on aconfiguration request sent by the management client 210. It may alsoactivate the validation mechanism 240 to perform consistency checking.When the configuration parameters in the temporary configurationdatabase are validated (consistent), the relay mechanism 220 may alsoactivate the transfer of the validated configuration parameters from thetemporary configuration database 230 to the configuration database 150.

When the management client 210 sends a parameter configuration requestto the configuration manager 215, the relay mechanism 220 receives therequest and identifies the appropriate module before relaying therequest to the identified module. The appropriate module may beidentified based on the registered modules stored in the module database265. For example, if a parameter configuration request instructs to setparameter A in module X to 2, the relay mechanism 220 analyzes therequest and verifies that module A is registered by looking up themodule database 265.

The configuration manager 215 enforces consistent parameterconfiguration via the validation mechanism 240. Configurationconsistency may be defined with respect to certain dependencyrelationships among different configuration parameters. There may bedifferent ways to define such dependency relationships. FIG. 3illustrates two exemplary ways to define a dependency 310. One is todefine through a hard coded dependency 320 and the other is to define aregistered dependency 330. The former (320) refers to a dependencyrelationship that is hard coded in the modules involved. A hard codeddependency may involve the dependency among different configurationparameters within the same module. For example, if the value ofparameter B in module X depends on the value of parameter A in module X(e.g., A=2, then B=3), parameter A and B form a dependency relationship.The dependency between A and B may be hard coded in module X and theconsistency may be enforced through both module X and the configurationmanager. This is discussed later in reference to FIG. 5 and FIG. 6.

A dependency may also be defined explicitly by registering thedependency relationship 330 with the configuration manager 215 via thedependency registration mechanism 260. Such registered dependencyrelationships are stored in the dependency database 270. A registereddependency may involve the dependency among different configurationparameters across modules. A registered dependency is therefore usuallydefined with respect to two modules, one being independent and the otherbeing dependent. For example, if the value of parameter B in module Ydepends on the value of parameter A in module X, module Y is defined asthe dependent module. Once the dependency relationship is registered andstored, a change to the value of parameter A in module X will triggerthe PCS 250 in the validation mechanism 240 to notify module Y toperform a change to parameter B accordingly so that the dependency ismaintained properly. Optionally, module Y may refuse to change the valueof B. In this case, the change made to parameter A may also be rejectedto maintain the consistency. For this reason, both A and B may have tobe changed within a single transaction.

An exemplary dependency registration process is described in FIG. 4. Anindependent parameter (e.g., parameter A) in the associated independentmodule (e.g., module X) is first specified and registered at act 420.Then the corresponding dependent parameter (e.g., parameter B) in adependent module (e.g., module Y) is specified and registered at act430. The independent parameter/module and the dependent parameter/moduleform a dependency relationship. The type of the relationship may bespecified further at act 440. For example, when A is changed to 2,module Y should be notified. The registered dependency relationship isthen stored in the dependency database at act 450.

Referring back to FIG. 2, the validation mechanism 240 may enforce theconsistency of configuration parameters by enforcing the dependencyrelationships specified among different configuration parameters ofembedded modules. To enforce a registered dependency relationship, thePCS 250 associated with the validation mechanism 240 may notify anembedded module about a change to a configuration parameter, which adifferent configuration parameter in a different embedded module dependson. For example, assume a configuration parameter B in embedded module Ydepends on a configuration parameter A in embedded module X (e.g., ifA=2, then B=3. If A=3, B=5.), and such a dependency relationship isregistered with the dependency registration mechanism 260 and stored inthe dependency database 270. When the value of parameter A in module Xis changed from value 2 to value 3, the validation mechanism 240notifies module Y to change its value accordingly. That is, thevalidation mechanism 240 monitors the changes made to configurationparameters, identifies the dependents of these parameters, and informsthe dependent modules to make changes accordingly so that theconsistency (or the dependency relationship) is maintained.

When an embedded module is notified of a change and is requested tochange the value of a dependent configuration parameter, the embeddedmodule may determine how to make the change to the dependentconfiguration parameter. That is, the task performed by the validationmechanism 240 may be limited to merely informing the dependent module tomake a change to a particular parameter (but not how to change). It mayalso be possible to implement the validation mechanism 240 in such a waythat it controls directly how to change the value of a dependentconfiguration parameter.

When an embedded module sets the value of a configuration parameter, itmay return a status code to the validation mechanism 240. Differentvalues of the returned status code may represent different outcomes. Forexample, the status code may be “OK”, representing the outcome that therequest is performed without any problem. The status code may also be“ERROR”, indicating that an error has occurred during the execution of aconfiguration request. An error may be due to an inconsistent parameterconfiguration. For example, if a configuration parameter is only allowedto be set to value 2 or 3 but a configuration request instructs theunderlying module to set the parameter value to 5. Status code mayrepresent an message that informs the validation mechanism 240 that theunderlying module has a hard coded dependency relationship that can notbe verified as consistent at the time being.

Depending on the status code returned from an underlying module, thevalidation mechanism 240 may react accordingly. For example, an errorcode may be forwarded back to the relay mechanism 220 and subsequentlysent to the management client so that an undo operation may beperformed. An undo operation may be implemented by simply ignoring allthe parameter configurations performed in the temporary configurationdatabase up to this point. That is, the temporary configuration database230 will not be copied to the configuration database 150. This yields anidentical effect as undo.

Whenever the return status code reports an “OK” status, the validationmechanism 240 may automatically proceed to enforce registered dependencyrelationships. The validation mechanism 240 may carry out an iterativevalidation process to enforce a registered dependency. For example, ifparameter B in module Y depends on parameter A in module X and when arequest to module X is made to change parameter A, the validationmechanism 240 identifies the corresponding registered dependency fromthe dependency database 270 and notifies module Y to revise the value ofparameter B. The notification may be triggered by an “OK” status codereturned by module X after module X changes the value of parameter A. Inthis way, the registered dependencies are automatically enforced.

When an “OK” status is received at the end of an iterative validationprocess, the validation mechanism 240 may inform the relay mechanism 220that the validation is complete. In this case, the relay mechanismnotifies the management client 210 of the completion of a request. Themanagement client 210 may then issue next request to the configurationmanager 215.

When the status code indicates using, for example, “REPEAT CALL”, thatthere exists a hard coded dependency relationship with respect to thecurrent request, the validation mechanism 240 may postpone thevalidation process until the end of the transaction. For example, assumeparameters A and B in module X have a dependency relationship (A=2, thenB=3. A=3, then B=5) hard coded in module X. When the management client210 first sends a request, via the configuration manager 215, to moduleX to change value of A to 3, the return status code from module X afterA is set to 3 may be a “REPEAT CALL”. The “REPEAT CALL” indicates thatthe consistency can not be checked at this point (because module X doesnot know whether there will be a future request in the same transactionthat instructs module X to change the value of B to 5). In this case,the validation mechanism 240 may not start the validation after all theconfiguration requests in the same transaction have been processed. Butthe validation mechanism 240 records these outstanding requests whosevalidity need to be checked at the end of the transaction.

When the management client 210 detects that all the configurationrequests 160 are processed in the temporary configuration database 230,it sends a command to the configuration manager 215 to perform aconsistency check. The relay mechanism 220 activates the validationmechanism 240. The validation mechanism 240 carries out the consistencycheck on all the outstanding requests and informs the management client210, via the relay mechanism 220, the outcome. If the outcome representsa consistent configuration, the management client 210 sends command tothe relay mechanism to commit the configuration. To commit theconfiguration, the configuration parameters stored in the temporarydatabase 230 are copied or transferred to the configuration database150. If the outcome indicates an inconsistent configuration, themanagement client 210 sends an undo command to the relay mechanism 220.To undo the configuration, the configuration parameters stored in thetemporary database 230 are ignored.

FIG. 5 is an exemplary flowchart of a process, in which consistentparameter configuration is performed. Prior to the execution ofconsistent parameter configuration, embedded modules 140 and some of thedependency relationships are registered at act 510. This may beperformed prior to the deployment of the embedded system 110. Toconfigure the embedded system 110, a set of configuration requests isreceived at act 515 and these configuration requests correspond to onesingle transaction. Upon receiving the configuration requests, themanagement client 210 informs the configuration manager to start a newtransaction. The configuration manager 215 creates, at act 520, thetemporary configuration database 230. The management client 210 thensends a request to the configuration manager 215 and the configurationmanager 215 relay the request, at act 525, to an appropriate embeddedmodule to perform the requested parameter configuration. The appropriatemodule executes, at act 530, the requested configuration and returns astatus code at act 535. The updates to the current configuration areperformed first in the temporary configuration database 230. Theconfiguration manager 215 examines the return status code at act 540 tosee whether it is an error. If it is an error code, the process proceedsto finish the transaction (will be described in reference to FIG. 7).When the status code does not indicate an error, the configurationmanager 215 proceeds to check the consistency against registereddependencies.

If there is any registered dependency associated with the currentconfiguration request, determined at act 550 by, for example, consultingwith the dependency database 270, the validation mechanism 240 notifiesthe dependent module that there has been a change made to itsindependent parameter in the independent module. For example, ifparameter B in module Y depends on parameter A in module X, theconfiguration manager 215 notifies module Y if the current configurationrequest involves a change to the value of parameter A in module X. Oncenotified, module Y may configure its dependent parameter B at act 530.As described earlier, module Y may refuse to configure parameter B.

The process of enforcing a registered dependency relationship may beiterative. For instance, there may be another parameter C in module Zthat is dependent on parameter B of module Y. In this case, thevalidation mechanism 240 further notifies module Z to change parameterC. The process loops through the acts between act 530 and 555 until allthe registered nesting dependencies associated with the currentconfiguration request are enforced.

The returned status code may also indicate that there is a hard codeddependency. For example, the status code may be “REPEAT CALL”,determined at act 560, indicating that at least some dependent parameterhas not been accordingly configured. In this case, the consistencyassociated with the hard coded dependency relationship can not bechecked until all the configuration requests in a transaction areprocessed. In the exemplary flowchart shown in FIG. 5, the validationmechanism 240 postpones such consistency check before the end of thetransaction and record current configuration request as an outstandingrequest at act 565. To allow the transaction to move forward, thevalidation mechanism 240 may also simply inform the management client210 an “OK” status at this point so that the management client 210 willproceed to send the remaining configuration requests. The acts between525 and 570 repeat until the end of the transaction.

At the end of the transaction, determined at act 570, the managementclient 210 ends the transaction and request the validation mechanism 240to proceed to check, at act 575, the consistency of the configurationsperformed in the transaction. The details of the consistency check arediscussed later with reference to FIG. 6. After the consistency check,the configuration manager 215 informs the management client 210 aboutthe status of the check and the management client 210 ends thetransaction at act 580 based on the consistency check outcome.

As discussed earlier, the configuration manager 215 may postpone theconsistency check associated with hard coded dependencies until all theconfiguration requests in a transaction have been processed. FIG. 6 isan exemplary flowchart that describes the process of consistencychecking at the end of a transaction. In FIG. 6, the management client210 sends a request at the end of a transaction, at act 610, to theconfiguration manager 215 to perform consistency check. Since theconsistency defined through registered dependencies has been validatedor enforced while the configuration requests are processed, theconsistency check at the end of a transaction may involve onlyvalidating the outstanding hard coded dependencies. What needs to bevalidated at this point includes the outstanding requests recorded bythe configuration manager 215. If there is no outstanding request,determined at act 620, the configuration manager 215 may simply returnan “OK” status at act 630 to the management client 210 as the outcome ofconsistency check.

If there is any outstanding request, the relay mechanism 220 triggersthe validation mechanism 240 to start a consistency check. For eachoutstanding request, the validation mechanism 240 sends, at act 640, theoriginal configuration request to the associated module. The originalconfiguration request instructs the associated module to change theindependent parameter in the hard coded dependency. For example, assumeparameter B depends on parameter A in module X. When an original requestto configure parameter A in module X is made, module X sets the value ofparameter A and then return a status code “REPEAT CALL” if the value ofparameter B is not consistent with the new value of parameter A. This isto indicate that it is not possible at this point to validate theconsistency. The validation mechanism 240 postpones the consistencycheck and records the original request to change parameter A in module Xas an outstanding request. When the consistency check is performed atthe end of the underlying transaction, the validation mechanism 240revisits the original request and requests, for the second time, moduleX to configure parameter A. At this point, if there has been a requestin the same transaction made to module X to configure parameter B (afterthe original request to configure A in module X and prior to the end oftransaction), the configuration may now be consistent and module X willreturn an OK status code. If not, module X will again return a “REPEATCALL” status code.

When a module with a hard coded dependency returns an “OK” status codein the second round, determined at act 650, the configuration manager215 proceed to handle the next outstanding request (back to act 620). Ifthe module returns another “REPEAT CALL” status code for the secondtime, the validation mechanism 240 examines whether the number ofoutstanding requests is decreased. If the number of outstanding requestis not decreased, determined at act 660, the validation mechanism 240sends an “ERROR” back to the management client 210 to indicate a failurein consistency check. If the number of outstanding requests is reducing,the validation mechanism 240 proceeds to handle the next outstandingrequest (back to act 620).

FIG. 7 is an exemplary flowchart of a process, in which the managementclient 210 reacts to different outcomes of a consistent check processand completes a transaction accordingly. There are two possible outcomesfrom consistency check: consistent configuration and inconsistentconfiguration. When the outcome indicates an inconsistent configuration,determined at act 710, the management client 210 sends an “UNDO” commandat act 720 to the configuration manager 215. Up on receiving the “UNDO”command, the configuration manager 215 deletes, at act 730, thetemporary configuration database 230 without changing the currentconfiguration stored in the configuration database 150.

When the management client 210 receives an outcome that indicates aconsistent configuration after the consistency check, it sends a“COMMIT” command at act 740 to the configuration manager 215. Up onreceiving the “COMMIT” command, the configuration manager 215 copy, atact 750, the new configuration stored in the temporary configurationdatabase 230 to the configuration database 150 to generate a new currentconfiguration of the embedded system 110. Based on the new currentconfiguration, corresponding changes are introduced, at act 760, torun-time variables. The temporary configuration database 230 is thendeleted at act 770.

While the invention has been described with reference to the certainillustrated embodiments, the words that have been used herein are wordsof description, rather than words of limitation. Changes may be made,within the purview of the appended claims, without departing from thescope and spirit of the invention in its aspects. Although the inventionhas been described herein with reference to particular structures, acts,and materials, the invention is not to be limited to the particularsdisclosed, but rather extends to all equivalent structures, acts, and,materials, such as are within the scope of the appended claims.

1. A system, comprising: at least one embedded module in an embedded system; and a consistent parameter configuration mechanism in the embedded system, communicating with the at least one embedded module to manage configuration parameters in a consistent fashion, wherein configuration parameters are configurable parameters forming a current configuration database that determines behavior of the embedded system, and wherein the consistent parameter configuration mechanism maintains configuration parameter dependency relationships associated with the at least one embedded module, wherein a configuration parameter dependency relationship defines a dependency relationship between at least two configuration parameters in the configuration database, the dependency being one of a dependency among configuration parameters within a single embedded module and a dependency among configuration parameters within different embedded modules.
 2. The system as recited in claim 1, wherein the consistent parameter configuration mechanism comprises: the current configuration database to store a set of configuration parameters of the embedded system, the set of configuration parameters having run-time counterpart variables in the at least one embedded module, the configuration database additionally to determine the behavior of the at least one embedded module and the embedded system; and a consistency assurance mechanism to ensure that the set of configuration parameters stored in the configuration database is consistent.
 3. The system as recited in claim 2, wherein the consistency assurance mechanism comprises: a management client to receive a set of configuration requests to configure at least one configuration parameter from the set of configuration parameters and to manage the execution of the set of configuration requests; and a configuration manager to manage the consistent configuration of the at least one configuration parameter according to the set of configuration requests, the configuration manager communicating with both the management client and the at least one embedded module to execute the set of configuration requests in a consistent fashion.
 4. A method for consistent parameter configuration in an embedded system, comprising: receiving, by a management client, a set of configuration requests, the set of configuration requests corresponding to a transaction wherein each configuration request comprises a request to set at least one configuration parameter, where configuration parameters are configurable parameters forming a current configuration database that determines behavior of the embedded system; creating, by a configuration manager, a temporary configuration database after the management client notifies the configuration manager of the start of the transaction; requesting an appropriate embedded module, the appropriate embedded module being one of a plurality of embedded modules, to perform a parameter configuration according to one of the configuration requests; performing, by the appropriate embedded module, the parameter configuration, the appropriate embedded module changing the value of a first parameter in the temporary configuration database and generating a first status code; returning the first status code to the configuration manager, and undoing the parameter configuration if the first status code indicates an error; recording the one of the configuration requests as an outstanding request if the first status code indicates that there is a hard coded dependency associated with the parameter configuration and defined based on the first parameter; enforcing, if the first status code is not an error, a registered dependency that is identified to associate with the parameter configuration and defined based on the first parameter; and maintaining configuration parameter dependency relationships associated with at least one embedded module, wherein a configuration parameter dependency relationship defines a dependency relationship between at least two configuration parameters in the configuration database, the dependency being one of a dependency among configuration parameters within a single embedded module and a dependency among configuration parameters within different embedded modules.
 5. The method as recited in claim 4, wherein the enforcing comprises: identifying a dependent embedded module which contains a second parameter that depends on the first parameter according to the registered dependency; and notifying the dependent embedded module to verify whether the first parameter remains consistent with the second parameter and to optionally configure the second parameter.
 6. The method as recited in claim 4, further comprising: examining, by the configuration manager, configuration consistency at the end of the transaction to generate a second status code; and finishing the transaction according to the second status code.
 7. The method as recited in claim 4, further comprising: registering, by a module registration mechanism prior to the receiving, the appropriate embedded module; and recording the appropriate embedded module, registered through the registering, in a module database.
 8. The method as recited in claim 5, further comprising: registering, by a dependency registration mechanism prior to the receiving, a dependency relationship that is used in the identifying to determine the consistency; and storing the dependency relationship as a registered dependency relationship in a dependency database.
 9. The method as recited in claim 8, wherein the registering includes: specifying an independent parameter associated with an independent embedded module, the independent parameter being configurable in the independent embedded module, the independent embedded module being one of the plurality of embedded modules; and specifying a dependent parameter associated with a dependent embedded module, the dependent parameter being configurable in the dependent embedded module, the dependent embedded module being one of the plurality of embedded modules, the independent embedded module and the dependent embedded module forming the registered dependency that triggers a parameter configuration to be performed on the dependent parameter whenever there is a change made to the independent parameter.
 10. The method as recited in claim 6, wherein the examining comprises: determining, by the configuration manager, whether there is an outstanding request recorded by the recording; sending the second status code indicating a consistent configuration if no outstanding request is recorded; requesting an embedded module to perform a second parameter configuration based on the outstanding request that defines the embedded module and the parameter to be configured through the parameter configuration; receiving a third status code specifying the status of the second parameter configuration; determining whether the number of outstanding request is reduced; and sending the second status code indicating an inconsistent configuration if the number of outstanding request is not reduced.
 11. The method as recited in claim 6, wherein the finishing comprises: determining whether the second status code indicates an inconsistent configuration; undoing the transaction if the second status code indicates an inconsistent configuration; and committing the transaction if the second status code indicates a consistent configuration.
 12. The method as recited in claim 11, wherein the undoing comprises sending a first command from the management client to the configuration manager; deleting, by the configuration manager, the temporary configuration database based on the first command.
 13. The method as recited in claim 11, wherein the committing comprises: sending a second command from the management client to the configuration manager; copying the content from the temporary configuration database to a configuration database based on the second command; introducing changes to run-time variables based on the configuration database; and deleting the temporary configuration database after the copying.
 14. A machine readable storage medium having instructions stored therein for maintaining consistent parameter configuration in an embedded system, when the instructions are executed causing the system to: receive, by a management client, a set of configuration requests, the set of configuration requests corresponding to a transaction wherein each configuration request comprises a request to set at least one configuration parameter, where configuration parameters are configurable parameters forming a current configuration database that determines behavior of the embedded system; create, by a configuration manager, a temporary configuration database after the management client notifies the configuration manager of the start of the transaction; request an appropriate embedded module, the appropriate embedded module being one of a plurality of embedded modules, to perform a parameter configuration according to one of the configuration requests; perform, by the appropriate embedded module, the parameter configuration, the appropriate embedded module changing the value of a first parameter in the temporary configuration database and generating a first status code; return the first status code to the configuration manager, and undoing the parameter configuration if the first status code indicates an error; record the one of the configuration requests as an outstanding request if the first status code indicates that there is a hard coded dependency associated with the parameter configuration and defined based on the first parameter; enforce, if the first status code is not an error, a registered dependency that is identified to associate with the parameter configuration and defined based on the first parameter; and maintain configuration parameter dependency relationships associated with at least one embedded module, wherein a configuration parameter dependency relationship defines a dependency relationship between at least two configuration parameters in the configuration database, the dependency being one of a dependency among configuration parameters within a single embedded module and a dependency among configuration parameters within different embedded modules.
 15. The medium as recited in claim 14, wherein the enforcing comprises instructions that when executed cause the system to: identify a dependent embedded module which contains a second parameter that depends on the first parameter according to the registered dependency; and notify the dependent embedded module to verify whether the first parameter remains consistent with the second parameter and to optionally configure the second parameter.
 16. The medium as recited in to claim 14, further comprising instructions to: examine, by the configuration manager, configuration consistency at the end of the transaction to generate a second status code; and finish the transaction according to the second status code, wherein finishing further comprises instructions to: determine whether the second status code indicates an inconsistent configuration; undo the transaction if the second status code indicates an inconsistent configuration; and commit the transaction if the second status code indicates a consistent configuration.
 17. The medium as recited by claim 14, further comprising instructions to: register, by a module registration mechanism prior to the receiving, the appropriate embedded module; and record the appropriate embedded module, registered through the registering, in a module database.
 18. The medium as recited by claim 15, further comprising instructions to: register, by a dependency registration mechanism prior to the receiving, a dependency relationship that is used in the identifying to determine the consistency; and store the dependency relationship as a registered dependency relationship in a dependency database.
 19. The medium as recited in claim 18, wherein the registering includes instructions to: specify an independent parameter associated with an independent embedded module, the independent parameter being configurable in the independent embedded module, the independent embedded module being one of the plurality of embedded modules; and specify a dependent parameter associated with a dependent embedded module, the dependent parameter being configurable in the dependent embedded module, the dependent embedded module being one of the plurality of embedded modules, the independent embedded module and the dependent embedded module forming the registered dependency that triggers a parameter configuration to be performed on the dependent parameter whenever there is a change made to the independent parameter.
 20. The medium as recited in claim 16, wherein the examining comprises instructions to: determine, by the configuration manager, whether there is an outstanding request recorded by the recording; send the second status code indicating a consistent configuration if no outstanding request is recorded; request an embedded module to perform a second parameter configuration based on the outstanding request that defines the embedded module and the parameter to be configured through the parameter configuration; receive a third status code specifying the status of the second parameter configuration; determining whether the number of outstanding request is reduced; and send the second status code indicating an inconsistent configuration if the number of outstanding request is not reduced. 